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BACKGROUND 

10 

Field of the Invention 

[0002] The invention is in the field of computer science and more specifically in the 
field of transaction management. 

1 5 Description of the Prior Art 

[0003] In a typical organization, sale of a product or service can impact multiple 
parties. For example, in a business environment such transactions may involve a sales 
team, their supervisors, their supporters and post sale personnel. In some cases it is 
desirable to distribute credit (e.g., commissions) for a sale or responsibility for a 

20 purchase, among these parties. 

[0004] Available software includes applications configured to track sales and 
distribute conmiissions to personnel within an organization. In these applications 
different personnel are assigned various allocation criteria for use in determining the 
transactions for which they should receive credit. For example, a sale may be associated 

25 with a specific sales territory, a specific product type, a sales team, an individual 

salesperson, a channel partner, a price range, a payment schedule, etc. Each of these 
characteristics may be associated with allocation criteria and used to determine one or 
more individuals who should receive credit for the sale. 
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[0005] In a typical prior art application, each transaction is individually examined and 
its characteristics are compared with each person's allocation criteria. When the 
characteristics match the criteria, the person. receives some credit for the transaction. In 
large organizations, these comparisons may include thousands of transactions and 
hundreds of personnel. The total number of comparisons is, therefore, large. 
[0006] Previously available systems have a number of drawbacks. For example, 
since each transaction is individually examined, the performance of these systems 
responds pooriy to increases in transaction volume. In addition, setup and maintenance 
of prior art systems are difficult since each person's allocation criteria is manually 
defined. Likewise, changes in products, personnel or organization sti^cture can require, 
possibly extensive, modification of system data. For example, when a new product is 
introduced the allocation criteria relating to each person who may receive credit for a sale 
of the product may need to be modified before an appropriate credit can be assigned. 
Finally, in existing systems, the ways in which credits are assigned can be unclear to 
personnel tracking or expecting to receive commissions. These systems often do not lend 
themselves well to the generation of reports tiiat itemize die commissions due to each 
person. 

[0007] There is a need for systems and methods to more efficiently manage allocation 
of transactions, such as sales commissions. For example, there would be a benefit to 
having systems capable of processing large numbers of transactions more efficientiy, 
automating aspects of allocation criteria management, or more clearly showing to a sales 
person how their conmiission was calculated. 
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[0008] Many systems and methods of allocating transactions include a problem of 
transactions that are unallocated, under-allocated, or over-allocated. For example, in 
some cases a sales transaction fails to meet the allocation criteria of any person to whom 
commission might be paid. In some cases, a sales transaction meets the allocation criteria 
5 of some people but not enough people to completely allocate the available commission. 
The existing art does not include efficient methods for allocating transactions that are 
unallocated, under-allocated or over-allocated. 
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SUMMARY OF THE INVENTION 
[0009] Embodiments of the invention include systems and methods of allocating 
transactions among a number of business objects. These business objects include, for 
example, individuals and/or organizations. The transactions typically involve payment of 
funds, such as sales commissions, but may also include allocation of inventory, 
movement of goods, or the like, as discussed further herein. Allocation is accomplished 
using predefined rules stored in a hierarchical data sti^cture tiiat is based on relationships 
between the business objects. The predefined rules and hierarchical data stiucture are 
used to form generated allocation rules associated with the business objects. The 
generated allocation rules are, in turn, used for allocating the transactions among the 
business objects. Each of the allocated transactions includes characteristics that can be 
determined to satisfy or not to satisfy a generated allocation rule. For example, in some 
embodiments, the business objects include individuals and groups within a company, die 
hierarchical data stixicture is based on the company organization and the generated 
allocation rules are used to determine sales conrniissions earned by each business object. 
[0010] Various embodiments of the invention include transaction filtering system for 
allocating transactions among a plurality of business objects, the system comprising 
storage configured to store generated allocation rules and to store transaction data 
associated with the plurality of transactions, each generated allocation rule being 
associated with at least one of the plurality of business objects and being generated using 
relationships between members of the plurality of business objects, and a query engine 
configured to query the transaction data using the generated allocation rules. 
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[0011] Various embodiments of the invention include a hierarchical data structure 
comprising a root node, one or more intermediate nodes related to the root node, one or 
more predefined rules, each predefined rule associated with a member of the one or more 
intermediate nodes, a leaf node, and a generated allocation rule associated with the leaf 
5 node and configured for use in determining allocation of transactions to a business object 
associated with the leaf node, the generated allocation rule including a member of the one 
or more predefined rules inherited fi-om the one or more intermediate nodes. 
[0012] Various embodiments of the invention include a computing system for 
hierarchical transaction filtering, the computing system comprising storage configured to 
10 store a hierarchical data structure, a generated allocation rule, and ti-ansaction data, a rule 
generation engine configured to produce the generated allocation rule using data stored in 
the hierarchical data structure, and a query engine configured to query the transaction 
data using the generated allocation rule. 

[0013] Various embodiments of the invention include a ti-ansaction allocation output 
15 comprising a set of transactions selected using a query, the query based on a generated 

allocation rule generated using a hierarchical data stiucture and associated with a leaf of 

the hierarchical data structure, at least two transactions of the set of tiransactions including 

a transaction value, and a summation of the ti-ansaction values. 
[0014] Various embodiments of the invention include a method of producing a 
20 generated allocation rule, the method comprising accessing a data stiucture including a 
root node, an intermediate node and a leaf node, reading the root node of the data 
structure, adding any predefined rule associated witii the root node to the generated 
allocation rule, ttaversing the data structure to the intermediate node, reading the 
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intermediate node, adding any predefined rule associated with the intermediate node to 
the generated allocation rule, traversing the data structure to the leaf node, adding any 
predefined rule associated with the leaf node to the generated allocation rule, and storing 
the generated allocation rule. 

5 [0015] Various embodiments of the invention include a method of producing a 
plurality of generated allocation rules, the method comprising accessing a hierarchical 
data structure including a plurality of nodes, and traversing the plurality of nodes, at each 
node ti-aversed, reading the ti-aversed node, combining any predefined rule associated 
with the ttaversed node with any of the plurality of generated allocation rules inherited 

10 from a parent node, to produce another of the plurality of generated allocation rules, 
associating the another of the plurality of generated allocation rules with the ttaversed 
node, storing the another of the plurality of generated allocation rules, and determining if 
all leaf nodes have been traversed. 

[0016] Various embodiments of the invention include a method of determining 
15 allocation of a plurality of ttansactions, the method comprising receiving first transaction 
data characterizing a first member of the plurality of ttansactions, receiving second 
transaction data characterizing a second member of the plurality of ttansactions, storing 
tiie first and second received ttansaction data, accessing a plurality of generated 
allocation rules, each of the plurality of generated allocation rules being associated with 
20 one of a plurality of business objects represented by an hierarchical data structure, 

executing a plurality of queries on the stored ttansaction data using a query engine, each 
of the plurality of queries being based on one of the plurality of generated allocation 
rules, and storing results of the executed queries. 
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[0017] Various embodiments of the invention include a method of generating a 
transaction allocation output, the method comprising receiving a query result including 
one or more transactions, the query result generated using a query, the query generated 
using a hierarchical data structure and the query associated with a leaf node of the 
5 hierarchical data stixicture, the query applied to a set of transactions, parsing each of the 
one or more transactions to determine a value of each of the one or more transactions, 
summing the values determined by parsing each of the one or more tiransactions, and 
including the sum of the determined values in the ti:ansaction allocation output. 
[0018] Various embodiments of the invention include a system for determining 
10 allocation of a plurality of transactions among a plurality of business objects, the system 
comprising storage configured for storing ti-ansaction data characterizing the plurality of 
transactions, means for producing a plurality of generated allocation rules, using 
relationships between nodes of a data stincture, means for executing a plurality of queries 
on ttie stored ti-ansaction data, using the plurality of generated allocation rules. 
15 [0019] Various embodiments of the invention include a computer readable medium 
storing computer code for producing a generated allocation rule, the computer code 
comprising a code segment for accessing a data structiire including a root node, an 
intermediate node and a leaf node, a code segment for reading the root node of the data 
stincture, a code segment for adding any predefined rule associated with the root node to 
20 the generated allocation rule, a code segment for traversing the data stiucture to the 

intermediate node, a code segment for reading the intermediate node, a code segment for 
adding any predefined rule associated with die intermediate node to the generated 
allocation rule, a code segment for ti-aversing the data sti\icture to the leaf node, a code 
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segment for adding any predefined rule associated with the leaf node to the generated 
allocation rule, and a code segment for storing the generated allocation rule. 
[0020] Various embodiments of the invention include a method of producing a 
generated allocation rule, the method comprising accessing a data structure including a 

5 root node, an intermediate node and a leaf node, reading the root node of the data 
structure, adding any predefined rule associated with the root node to the generated 
allocation rule, traversing the data structure to the intermediate node, reading the 
intermediate node, adding any predefined rule associated with the intermediate node to 
the generated allocation rule, traversing the data structure from the intermediate node, 

10 reading the leaf node, adding any predefined rule associated with the leaf node to the 
generated allocation rule, and storing the generated allocation rule. In some of these 
embodiments, traversing the data structure from the intermediate node includes traversing 
the data structure to the leaf node. In some of these embodiments, traversing the data 
structure from the intermediate node includes traversing the data structure to the root 

15 node. 

[0021] Various embodiments of the invention include a transaction filtering system 
for allocating transactions among a plurality of business objects, the system comprising 
storage configured to store generated allocation rules and to store transaction data 
associated with the plurality of transactions, each generated allocation rule being 
20 associated with at least one of the plurality of business objects and being generated using 
relationships between members of the plurality of business objects, a query engine 
configured to query the transaction data using the generated allocation rules, and an 
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allocation manager configured to make one or more attempts to allocate a member of the 
plurality of transactions among the plurality of business objects. 
[0022] Various embodiments of the invention include a hierarchical data structure 
comprising a root node, one or more intermediate nodes related to the root node, a leaf 
node, and a first generated allocation rule associated with the leaf node and configured 
for use in determining allocation of transactions to a business object associated with the 
leaf node, a second generated allocation rule associated with one of the one or more 
intermediate nodes and configured for use in determining a business object configured to 
manually determine the allocation of one of the transactions to a business object. 
[0023] Various embodiments of the invention include a computing system for 
hierarchical transaction filtering, the computing system comprising storage configured to 
store a hierarchical data structure, a first generated allocation rule, a second generated 
allocation rule, and transaction data, an allocation manager configured to track allocation 
of transactions represented by the transaction data, and a query engine configured to 
execute a first query on the transaction data using the first generated allocation rule and, 
responsive to the first query, to execute a second query on the transaction data using the 
second generated allocation rule. 

[0024] Various embodiments of the invention include a transaction allocation output 
comprising a first set of transactions selected using a first query, the first query based on 
an allocation rule generated using a hierarchical data structure and associated with a leaf 
node of the hierarchical data structure, at least one transaction of the first set of 
transactions including a transaction value, a second set of transactions whose allocation is 
determined by a business object, the business object being identified using a second 
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query, at least one transaction of the second set of transactions including a tiransaction 
value, and a summation of the transaction values. 

[0025] Various embodiments of die invention include a method of determining 
allocation of one or more transactions, the method comprising accessing a first allocation 
5 rule associated with one of a plurality of business objects represented by a hierarchical 
data stiaxcture, executing a first query on tiansaction data using a query engine, the first 
query being based on the first allocation rule, the ti-ansaction data characterizing the one 
or more ti-ansactions, accessing a second allocation rule associated with another of the 
plurality of business objects represented by the hierarchical data stinicture, and executing 
10 a second query on a subset of the transaction data using the query engine, the second 
query being based on the second allocation rule and identifying a business object for 
determining allocation of at least one of the one or more ti-ansactions. 
[0026] Various embodiments of the invention include a method of generating a 
transaction allocation output, the method comprising receiving a query result including 
15 one or more ti-ansactions, the query result generated using a query applied to a set of 
transactions, the query generated using a hierarchical data structure and the query 
associated with a leaf node of the hierarchical data stinicture, determining tiransaction 
allocation of any of the one or more ti-ansactions that are unallocated, under-allocated, or 
over-allocated, parsing each of the one or more transactions to determine a value of each 
20 of the one or more ti-ansactions, summing the values determined by parsing each of the 
one or more ttansactions, and including the sum of the determined values in the 
transaction allocation output. 
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[0027] Various embodiments of the invention include a system for determining 
allocation of a plurality of transactions among a plurality of business objects, the system 
comprising, storage configured for storing transaction data characterizing the plurality of 
transactions, means for executing a plurality of queries on the stored transaction data, 
5 using a plurality of allocation rules, the queries configured to determine allocation of the 
plurality of transactions, and means for manually determining allocation of a subset of the 
plurality of transactions, the subset including unallocated, under-allocated or over- 
allocated transactions. 

[0028] Various embodiments of the invention include a computer readable medium 
10 storing computer code for determining an allocation plan, the computer code comprising 
a code segment for accessing a first allocation rule associated with one of a plurality of 
business objects represented by a hierarchical data structure, a code segment for 
executing a first query on transaction data using a query engine, the first query being 
based on the first allocation rule, the transaction data characterizing the one or more 
15 transactions, a code segment for accessing a second allocation rule associated with 

another of the plurality of business objects represented by the hierarchical data structure, 
and a code segment for executing a second query on a subset of the transaction data using 
the query engine, the second query being based on the second allocation rule and 
identifying a business object for determining allocation of at least one of the one or more 
20 transactions. 
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BRffiF DESCRIPTION OF THE VARIOUS VEWS OF THE DRAWING 
[0029] FIG. 1 illustrates a hierarchical transaction filtering system according to 
various embodiments of the invention; 

[0030] FIG. 2 illustrates hierarchical relationships between a set of business objects 
5 according to various embodiments of the invention; 

[0031] FIG. 3 illustrates a method of determining a generated allocation rule 
according to various embodiments of the invention; 

[0032] FIG. 4 illustrates an alternative method of determining a generated allocation 
rule according to various embodiments of the invention; 
10 [0033] FIG. 5 illustrates a method of allocating a plurality of transactions according 
to various embodiments of the invention; and 

[0034] FIG. 6 illustrates a method of generating a transaction allocation output 
according to various embodiment of the invention; 

[0035] FIG. 7 illustrates a hierarchical data structure according to various 
15 embodiments of the invention; and 

[0036] FIG. 8 illustrates a method of allocating transactions according to various 
embodiments of the invention. 
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DISCLOSURE OF THE INVENTION 
[0037] Embodiments of the invention include systems and methods of generating 
allocation rules and using these generated allocation rules to allocate transactions, such as 

5 payment of sales commissions, among members of an organization. Each of these 
members are represented by a node in a hierarchical data structure and are optionally 
associated with some predefined rule (e.g., allocation criteria). Generated allocation 
rules, used for performing an allocation, are produced using the predefined rule and 
associations implied by the hierarchical data structure. For example, in some 

10 embodiments, each node in the hierarchical data structure is associated with a generated 
allocation rule produced by combining any associated predefined rule with a generated 
allocation rule inherited from a parent node. Through this process of inheritance and 
combination, a generated allocation rule is determined for each node in the hierarchical 
data structure. These generated allocation rules are then used to select transactions to be 

15 allocated to the members associated with the nodes of the hierarchical data structure. 
[0038] In a typical embodiment, each member of an organization is treated as a 
business object associated with a node in the hierarchical data structure. Generated 
allocation rules, associated with the node and the business object, are derived through a 
process that includes combining any predefined rule characterizing the business object 

20 with any allocation rule (e.g., generated allocation rule) inherited from a parent node. 
Through inheritance of allocation rules, each node (other than a root node) is associated 
with a generated allocation rule that is an aggregation of the predefined rule associated 
with its parent nodes, and grandparent nodes, etcetera, in the hierarchical data structure. 
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Generated allocation rules are produced as the hierarchical data structure is developed or 
by traversing the hierarchical data sti^cture in an orderly manner. When a business 
object is not characterized by any predefined rule, the generated allocation rule associated 
with the business object, and corresponding node, is determined by inheritance from a 
5 parent node. 

[0039] In a typical method of the invention, sales data are received and stored in a 
database as ti-ansactions to be allocated. In order to allocate these ti-ansactions among 
business objects, the database is queried using queries based on the generated allocation 
rules. Each query is used to select those ti-ansactions that satisfy the predefined rules 
10 included in a particular generated allocation rule and the selected transactions are 
allocated to a business object associated with that generated allocation rule. Thus, a 
particular person is allocated tiansactions whose characteristics match the generated 
allocation rule associated with that person, and the allocated ti-ansactions are selected 
using a query based on the associated generated allocation rule. Using this approach, a 
15 large number of tiansactions can be allocated using a small number of queries, because 
the number of queries is responsive to the number of business objects not the number of 
transactions. When tiie number of tiansactions significantiy outnumbers the number of 
business objects, this approach is typically more efficient than individually comparing 
each transaction with a set of allocation rules. 
20 [0040] In various embodiments, business objects include individual persons, groups, 
organizations, corporations, geographic locations, projects, products, production 
resources, tasks, or tiie like. In these embodiments, tiansactions optionally include sales, 
sales commissions, purchases, purchase costs, inventory allocation, allocation of financial 
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resources, allocation of capital resources, tasks, steps in a process, compensation, quality 
control, billing, or the like. For example, in one embodiment the business object is a task 
and the transaction is an inventory allocation to that task. In another embodiment, the 
business object is a person and the transaction is a task (e.g., a sales call) that can be 
assigned to a person. In another embodiment the business object is a shipping resource 
(e.g., a cargo carrier) and the transaction is a transportation task. In some embodiments, 
the transactions include sales and associated sales commissions, and the business objects 
include members of a sales team and associated parties. For the purposes of example, 
these embodiments will be discussed further herein. However, the methods and systems 
discussed in relation to these embodiments are readily applied to alternative embodiments 
of the invention including other types of business objects and transactions, without going 
beyond the intended scope of the invention. 

[0041] In many businesses, sales are achieved as the result of a team effort involving 
sales personnel, marketing personnel, channel partners, sales engineers and managers. 
When a sale occurs, a conrniission or other credit is to be allocated among the parties 
who contributed to the sale. Typically, each party (e.g., business object) is associated 
with a generated allocation rule or set of generated allocation rules that determine if the 
party is entitled to an allocation from a particular sale. Each sale (e.g., transaction) is 
characterized by attributes that can be compared with the generated allocation rules. For 
example, a particular sales person may be associated with a generated allocation rule that 
specifies allocation of 2% of sales revenue within a particular geographic region, 1% of 
sales from a particular product line, 2% of sales to a particular customer, and 0.5% of 
sales by other members of her sales team. In this example, a transaction may be 
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characterized by a geographic location, a product, a customer and a sales team. A wide 
variety of such allocation schemes are known in the art. In the invention, these schemes 
are expressed as generated allocation rules' derived from a hierarchical data structure. 
Each condition, such as "2% of sales to a particular customer," is considered a predefined 
5 rule. 

[0042] FIG. 1 illustrates a Transaction Filtering System 100 according to various 
embodiments of the invention. Transaction Filtering System 100 includes a Computing 
System 110 optionally accessible through a Client 120 and configured to receive 
transactions from a Transaction Source 130. Computing System 110 may be a single 

10 computing device or a set of interconnected computing devices. The set of 

interconnected computing devices optionally includes both local and remote devices. In 
typical embodiments, Client 120 includes a computing device such as a computer, 
personal digital assistant, network access device, or the like. Client 120 optionally 
accesses Computing System 110 though a network such as the Internet, local area 

15 network, wide area network, or the like. In some embodiments. Computing System 1 10 
is accessed through a browser supported by Client 120. 

[0043] Transaction Source 130 is a source of transactions to be allocated. For 
example, in various embodiments. Transaction Source 130 is a point-of-sale system, an 
accounting system, a sales reporting system, an inventory system, a task management 
20 system, or the like. Transaction Source 130 is optionally supported by elements of 
Computing System 110. For example, in some embodiments. Transaction Source 130 
includes a sales accounting program executing on Computing System 110. 
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[0044] Computing System 1 10 includes Storage 140 configured to store data 
associated with systems and methods of the invention. For example. Storage 140 is 
typically configured to store Organizational Data 145. Rule Data 150 and Transaction 
Data 155. Organizational Data 145 includes a hierarchical data structure configured to 

5 store relationships between business objects. An example of Organizational Data 145 is 
illustrated by HG. 2 as discussed further herein. Rule Data 150 includes generated 
allocation rules associated with business objects characterized by information within 
Organizational Data 145. These generated allocation rules are produced using a Rule 
Generation Engine 160. The generation process is furtiier described witii reference to 

10 HGs. 3 and 4. Transaction Data 155 includes transactions received from Transaction 

Source 130. In a typical embodiment, a plurality of ti-ansactions are stored in Transaction 
Data 155. 

[0045] A Query Engine 170 is configured to execute queries based on Rule Data 150. 
In a typical embodiment, each generated allocation rule within Rule Data 150 is 
15 processed to place the generated allocation rule in a stiiictured query language (SQL) 

format. In some embodiments, the generated allocation rules are stored in Rule Data 150 
as SQL queries and can be used by Query Engine 170 without mocUfication. The 
generated allocation rule based queries are used to select transactions stored in 
Transaction Data 155. 

20 [0046] Results of queries executed using Query Engine 170 are passed through an 
Output Interface 180 to generate a transaction allocation output that is optionally 
accessible to Client 120. Output Interface 180 is optionally configured to format the 
results in a report format including data such as a summation of selected ti^nsaction 
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values. In some embodiments, the transaction allocation output is generated in a meta- 
language format such as HTML, or the like. 

[0047] Query Engine 170 and optionally Output Interface 180 are responsive to an 
Allocation Manager 190. Allocation Manager 190 includes computer code configured to 

5 manage and optionally coordinate the functions carried out by other aspects of 

Computing System 110. For example, in some embodiments, Allocation Manager 190 
keeps track of the progress made in allocating a set of transactions according to an 
allocation plan. An allocation plan is a plan for allocating transactions to/among a set of 
business objects. In some embodiments, Allocation Manager 190 is configured to make 

10 several attempts to allocate a particular transaction. In some embodiments. Allocation 
Manager 190 tracks unallocated transactions, under-allocated transactions, and/or over- 
allocated transactions. 

[0048] FIG. 2 illustrates a Hierarchical Data Structure, generally designated 200, 
according to some embodiments of the invention. In these embodiments. Hierarchical 

15 Data Structure 200 is included in Organizational Data 145 (HG. 1) and is used to store 
relationships between a set of Business Objects, 210A-210W. Business Objects 210A- 
210W include geographic regions (210A-210F), sales channel types (210G-210H), 
product types (210I-210J), individual sales people (210K-210W), or the like. In this 
example, Business Object 210A is represented by a root node of Hierarchical Data 

20 Structure 200. Business Objects 210B-210J and 210P are represented by intermediate 
nodes and Business Objects 210K-210N and 210Q-210W are represented by leaf nodes. 
[0049] In some embodiments, an individual sales person is optionally associated with 
more than one Business Object 210. For example, a sales person may be involved with 



Solberg et al. 



18 



PA2552US 



both direct sales in the west and hardware sales in Ohio, and thus be both Business 
Objects 210K and 210T. A sales person is also optionally represented by an intermediate 
node such as Business Object 210P. The relationships between Business Object 210P 
(intermediate node) and Business Objects 210Q-210S (leaf nodes) may, for example, be 
5 that of sales group leader and sales group members. Some of Business Objects 210A- 
210W are optionally representative of different organizations (e.g., companies, divisions, 
or groups). For example. Business Objects 210M-210S may be representative of a 
separate channel partner company. 

[0050] In a typical embodiment, each of Business Objects 210A-210W is associated 
10 with at least one generated allocation rule. These generated allocation rules are produced 
by Rule Generation Engine 160 (FIG. 1) using an inherited allocation rule and any 
predefined rule characterizing a particular member of Business Objects 210A-210W. For 
example. Business Object 210B inherits a generated allocation rule from Business Object 
210A. In the illustrated example this generated allocation rule may be "a sale within the 
15 United States territory." In addition. Business Object 210B is characterized by a 
predefined rule "a sale within the West territory." The generated allocation rule 
associated with Business Object 210B may, therefore, be the combination of the inherited 
rule and the predefined rule, resulting in a generated allocation rule of "a sale within the 
United States territory and a sale within the West territory." Likewise, generated 
20 allocation rules for Business Objects 210G and 210H may be "a sale within the United 
States territory, a sale within the West territory and a direct sale" and "a sale within the 
United States territory, a sale within the West territory and a channel partner sale," 
respectively. 
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[0051] The embodiment of Hierarchical Relationship Structure 200 illustrated in HG. 
2 includes a single parent node for each node other than the root node (Business Object 
210A). This structure simplifies inheritance of generated allocation rules from each 
parent node to each daughter node. However, in altemative embodiments, any of 
5 Business Object 210B-210W may appear more than once in Organizational Data 145. In 
some embodiments, a particular Business Object 210 inherits generated allocation rules 
from more than one parent node. The inheritance approach to production of generated 
allocation rules, as employed by Rule Generation Engine 160, is possible as long as there 
are a finite number of paths between each node and the root node, (i.e., no circular paths 
10 exist). Thus, while a hierarchical data structure is disclosed for illustrative purposes, 
embodiments of the invention include other relational data models accommodating the 
principle of inheritance. In some embodiments, of the invention, not all nodes are 
associated with a member of Business Objects 210A-210W. For example, some data 
structures, such as a binary tree representation of Hierarchical Data Structure 200, include 
15 nodes used primarily for navigation. In some embodiments, only leaf nodes are 

associated with a member of Business Objects 210A-210W and intermediate nodes are 
used for navigating the data structure. Even when not associated with a member of 
Business Objects 210A-210W, a node may optionally be associated with a predefined 
allocation rule. 

20 [0052] FIG. 3 illustrates a method of determining a generated allocation rule 

according to various embodiments of the invention. In an optional Generate Hierarchical 
Data Structure Step 300, Organizational Data 145, such as that illustrated in FIG. 2 is 
generated and stored in Storage 140. This step includes establishing hierarchical 
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relationships between Business Objects 210A-210W and/or defining predefined rules 
characterizing Business Objects 210A-210W. This step may be avoided when previously 
existing data is used. Generate Hierarchical Data Structure Step 300 is optionally an 
ongoing process wherein Organizational Data 145 is updated by addition, deletion or 
5 otiier modification of Business Objects 210A-210W, over time. 

[0053] In a Read Root Node Step 3 10, a root node of Hierarchical Data Structure 200 
(e.g., the node representing Business Object 210A) is accessed using Rule Generation 
Engine 160. From this node all the nodes within Organizational Data 145 are accessible. 
In some embodiments, this access includes passing a pointer referencing a memory 
10 location wherein Business Object 210A is stored, to Rule Generation Engine 160. Read 
Root Node Step 310 typically includes reading any predefined rule characterizing 
Business Object 210A. 

[0054] In an Add Root Node Criteria Step 320, any predefined rule characterizing 
Business Object 210A is added to the allocation rule being generated. The result of this 

15 addition is a generated allocation rule, for the root node, and associated with Business 
Object 210A. After this step, the generated allocation rule associated with Business 
Object 210A may include only the predefined rule characterizing Business Object 210A, 
or alternatively, may also include a default predefined rule introduced by Rule 
Generation Engine 160. This predefined rule may include, for example, filtering criteria 

20 based on the characteristics of the transaction (such as sales amount), or characteristics of 
the business object (such as product cost). 

[0055] In a Traverse to Node Step 330, Hierarchical Data Structure 200 is traversed 
to another node representing one of Business Objects 210B-210W. Traversal of 
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Organizational Data 145 is typically accomplished using one of the many algorithms 
known in the art for navigating a data structure. Once Rule Generation Engine 160 
traverses to a node within Organizational Data 145 that node is considered the "current" 
node upon which Rule Generation Engine 160 performs operations. In Read Node Step 
5 340, any predefined rule associated with the current node is read by Rule Generation 
Engine 160. 

[0056] In an Add Node Criteria Step 350 the read predefined rule is added to any 
generated allocation rule inherited from a parent node of the current node. Typically, 
each node other than the root node has one parent node from which a generated allocation 

10 rule is inherited. The combination of the inherited generated allocation rule and the read 
predefined rule forms a generated allocation rule for the current node and any associated 
member of Business Objects 210B-210W. In alternative embodiments, a node may 
inherit allocation rules from more than one parent node. In these embodiments, tiie 
generated allocation rule for the current node is the combination of all inherited 

15 allocation rules and any read predefined rules. 

[0057] In a Store Allocation Rule Step 360, the generated allocation rule associated 
with the node is stored in Rule Data 150 (FIG. 1). The storage is optionally in a format 
accessible to Query Engine 170. In some embodiments, Query Engine 170 is configured 
to generate a query based on each of the stored rules and in other embodiments the rules 

20 are stored directiy as formatted queries. In alternative embodiments, the generated 
allocation rules are stored in Rule Data 150 after each rule is completed. 
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[0058] As determined in a Step 370, if there are further nodes, that have not been 
read using Read Node Step 340, then the method returns to Traverse to Node Step 330. 
This process is typically repeated until all nodes have been visited. 
[0059] HG. 4 illustrates an alternative method of determining a generated allocation 
rule according to various embodiments of the invention. In this embodiment, generated 
allocation rules are produced during development of Hierarchical Data Structure 200. In 
a Define Root Node Step 410, a root node associated with Business Object 210A is 
defined. This node serves as a root for Hierarchical Data Structure 200, including nodes 
associated with Business Objects 210A-210W. Define Root Node Step 410 optionally 
includes specification of a predefined rule characterizing Business Object 210A. 
[0060] In an optional Define Root Node Allocation Rule Step 420, Rule Generation 
Engine 160 is used to define a generated allocation rule associated with the root node. 
The generated allocation rule is produced by combining any default rule received fi-om 
Rule Generation Engine 160 with any predefined rule specified in Define Root Node Step 
410. 

[0061] In a Define Daughter Node Step 430, a daughter node, optionally associated 
with a member of Business Objects 210B-210W, is defined. The daughter node may be 
either an intermediate node or a leaf node. The first time Define Daughter Node Step 430 
is executed the defined node will be a daughter of the root node. In subsequent 
executions, the defined node may be a daughter of either the root node or an intermediate 
node. Define Daughter Node Step 430 optionally includes specification of a predefined 
rule characterizing a member of Business Objects 210B-210W associated with the 
defined daughter node. 
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[0062] In an Inherit Rule Step 440, the daughter node, defined in Define Daughter 
Node Step 430. inherits a generated allocation rule from its parent node. In alternative 
embodiments, die daughter node has more than one parent node and optionally inherits a 
generated allocation rule from each parent node. 
5 [0063] In a Modify Rule Step 450, the inherited allocation rule is modified by adding 
any predefined rule characterizing the member of Business Objects 210B-210W 
associated with the defined daughter node. The result of this addition is a new generated 
allocation rule associated witii the daughter node. Steps 430 through 450 are repeated as 
needed as new nodes and associated Business Objects 210B-210W are added to 
10 Hierarchical Data Structure 200. 

[0064] The methods illustrated in HG. 3 and HG. 4 are optionally both used in the 
same embodiments of the invention. For example, in some embodiments, the method 
illustrated by HG. 4 is used when Hierarchical Data Structure 200 is first developed and 
the metiiod illustrated by FIG. 3 is used to update generated allocation rules if 
15 Hierarchical Data Structure 200 has been modified. This modification optionally 

includes, for example, addition or deletion of nodes, changes in predefined rules, changes 
in associations between nodes and/or Business Objects 210A-210W, or the like. In 
various embodiments, data generated in Define Root Node Step 410 and Define Daughter 
Node Step 430 are stored in Organizational Data 145 (HG. 1). while data generated in 
20 Define Root Node Allocation Rule Step 420 and Modify Rule Step 450 are stored in Rule 
Data 150. 

[0065] HG. 5 illustrates a method of allocating a plurality of transactions according 
to various embodiments of the invention. In a Receive Transactions Step 510 transaction 
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data characterizing transactions are received from Transaction Source 130 (FIG. 1). For 
example, in some embodiments, Transaction Source 130 includes records of sales entered 
by individual sales personnel or their managers. In a Store Transactions Step 520, the 
transactions received in Receive Transactions Step 510 are stored in Storage 140 as 
Transaction Data 155. In some embodiments, this storage is accomplished using an SQL 
compatible database. Typically, a number of transactions are stored before completion of 
Receive Transactions Step 510 and Store Transactions Step 520. In some embodiments, 
because the number of queries made to allocate the stored transactions is based upon the 
number of generated allocation rules used for allocating those transactions, rather than 
upon the number of transactions, further benefit is achieved when the number of 
transactions is greater than the number of generated allocation rules. 
[0066] In an Access Rules Step 530, Query Engine 170 is used to access Rule Data 
150 and the generated allocation rules stored therein. The accessed generated allocation 
rules include those generated allocation rules produced using Organizational Data 145 
and Rule Generation Engine 160. In an Execute Queries Step 540, Query Engine 170 is 
used to perform queries on the transactions received in Receive Transactions Step 510. 
These queries are based on the generated allocation rules accessed in Access Rules Step 
530. In some embodiments, the generated allocation rules are retrieved in a query 
format, such as SQL, while in other embodiments the generated allocation rules are 
formatted in Execute Queries Step 540 to form queries for execution. In some 
embodiments, a query is executed for each generated allocation rule. In some 
embodiments, a query is executed for each generated allocation rule associated with a 
leaf node. For example, in embodiments of Hierarchical Data Structure 200, wherein 
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only leaf nodes are used to represent Business Objects 210A-210W, only the generated 
allocation rules associated with these leaf nodes are needed for allocation. 
[0067] In an optional Store Query Result Step 550, results of queries executed in 
Execute Queries Step 540 are stored. Storage may occur on Storage 140, Client 120, or 
5 another computing device. Typically, the query results include those transactions that 
match the generated allocation rules associated with each of Business Qbjects 210A- 
210W. Each query executed in Execute Queries Step 540 serves to select transactions to 
be allocated to a member of Business Objects 210A-210W. In some embodiments, a 
transaction can be allocated to more than one member of Business Objects 210A-210W. 
10 [0068] In the method illustrated by FIG. 5, transactions are optionally allocated in 
separate stages. For example, in one embodiment wherein Business Object (Channel 
Partner) 210H (FIG. 2) is a separate company, a benefit is achieved by allocating 
transactions to Business Object 210H and then allowing the separate company to allocate 
these transactions among Business Objects 210M-210S in a separate stage. Thus, each 
15 allocation is optionally viewed as a Transaction Source 130 to a separate stage of the 
invention. In one embodiment, the generated allocation rules used to allocate 
transactions to Business Object 210H are not revealed to Business Object 210H. 
Furthermore, in one embodiment, only transactions allocated to Business Object 210H 
are revealed to Business Object 210H. 
20 [0069] FIG. 6 illustrates a method of generating a transaction allocation output 

according to various embodiment of the invention. In a Receive Query Result Step 610 a 
query result, including selected transactions, is received. This query result is, for 
example, a query result stored in Store Query Result Step 550 of FIG. 5. The received 
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query result is generated using a query based on a hierarchical organizational data (e.g.. 
Hierarchical Data Structure 200). Examples of steps included in this generation process 
are illustrated by HG. 3 and HG 4. 

[0070] In a Parse Transactions Step 620, the selected transactions received in Receive 
5 Query Result Step 610 are parsed. During the parsing process transaction values are 

identified. In various embodiments, these transaction values are, for example, the amount 
of a sale, the amount of a sales commission, the amount paid by a customer, the cost of a 
sale, an inventory allocation, or the like. 

[0071] In a Sum Transaction Values Step 630 the transaction values identified in 
10 Parse Transactions Step 620 are summed. In alternative embodiments, alternative or 
additional mathematical operations are performed on these transaction values. In an 
Include Sum Step 640, the result of the mathematical operation, performed in Sum 
Transactions Values Step 630, are included in the transaction allocation output. In 
various embodiments, of the invention, the transaction allocation output is a printed 
15 output, a display output, a digital electronic output, a saved output, or the like. For 
example, in some embodiments, the transaction allocation output is displayed and/or 
printed using Client 120. 

[0072] FIG. 7 illustrates an alternative ffierarchical Data Structure, generally 
designated 700, including Root Node 710, Intermediate Nodes 720A-720H, and Leaf 
20 Nodes 730A-730N. In Hierarchical Data Structure 700, business objects configured to 
receive transaction allocations are associated with at least one of Leaf Nodes 730A-730N. 
While Root Node 710 and Intermediate Nodes 720A-720H are optionally associated with 
predefined rules, generated allocation rules, and/or business objects, those business 
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objects, with which Root Node 710 and Intermediate Nodes 720A-720H are associated, 
are not necessarily configured to receive transaction allocations. For example, in the 
illustrated example, Intermediate Note 720B is associated with an Eastern sales division. 
Because the Eastern sales division is an organizational business object and not an 

5 individual person it may not be configured to receive some types of transaction 

allocations (e.g. a commission). Root Node 710 and Intermediate Nodes 720A-720H 
each optionally have at least one daughter node that is a leaf node 730A-730N. This 
daughter node may be associated with a manager of the business object associated with 
its parent node. For example. Leaf Node 730C, a daughter node of Intermediate Node 

10 720B, may be associated with an Eastern sales division manager. 

[0073] In the above case, the business object associated with Leaf Node 730C has a 
"management" role with respect to Intermediate Node 720B. In alternative 
embodiments, this management role is held by a business object associated with a node 
other than an immediate daughter node. For example, the business object associated with 

15 Leaf Node 730G may have a management role with respect to the business objects 
associated with both Intermediate Nodes 720D and 720F. The management role with 
respect to the business object associated with Intermediate Node 720H is illustrated by a 
Dotted line 740. 

[0074] In some embodiments. Root Node 7 10 and/or specific members of 
20 Intermediate Nodes 720A-720H are associated with a predefined rule but not with a 
business object. In some embodiments. Root Node 710 and/or specific members of 
Intermediate Nodes 720A-720H are associated with a predefined rule and a business 
object that is not configured to receive a transaction allocation. This business object may 
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be, for example, a product classification. Members of Intermediate Nodes 720A-720H 
having different types of associations can be found in a single instance of Hierarchical 
Data Structure 700. 

[0075] In embodiments of the invention iUusttated by FIG. 7, ti-ansactions are 
allocated by executing queries based on the generated allocation rules associated witii 
Leaf Nodes 730A-730N. In these embodiments, it is not necessary to execute queries 
based on any generated allocation rules associated with Root Node 710 or Intermediate 
Nodes 720A-720H in order to allocate transactions. However, as is shown further herein, 
these generated allocation rules are optionally used for processing of tiransactions that are 
unallocated, under-allocated or over-allocated, using the allocation rules associated with 
Leaf Nodes 730A-730N alone. 

[0076] In various embodiments of the invention, a first attempt at allocating a set of 
transactions is made using generated allocation rules associated with leaf nodes, such as 
Leaf Nodes 730A-730L. This process is similar to that discussed with respect to FIG. 5, 
except tiiat the queries executed in Execute Queries Step 540 are based on generated 
allocation rules associated with leaf nodes and those transactions not selected by any 
query are identified. After Execute Queries Step 540, any transactions not completely 
allocated are optionally identified. 

[0077] In a second attempt at transaction allocation, the identified (unallocated, 
under-allocated, or over-allocated) tiransactions are queried using queries based on 
generated allocation rules associated with root or intermediate nodes, such as Root Node 
170 and/or Intermediate Nodes 720A-720H. In some embodiments, the generated 
allocation rule associated with Root Node 710 is configured to select all possible 
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transactions. Thus, in these embodiments, all transactions not selected on the first 
allocation attempt are selected on the second allocation attempt by at least one query. 
Results of the second allocation attempt are used to determine, through additional steps, 
allocation of the identified transactions to business objects. 

5 [0078] FIG. 8 illusti^tes an example of an allocation metiiod used to allocate 

transactions according to various embodiments of the invention. In tiiese embodiments, 
several attempts are made to allocate ti-ansactions and the additional attempts are 
configured to allocate transactions that were unallocated, under-allocated or over- 
allocated in a first attempt. The method of FIG. 8 includes using Hierarchical Data 

10 Smicture 700 to allocate transactions that were unallocated, over-allocated or under- 
allocated transactions in a previous attempt at allocation. In an Access Leaf Rules Step 
810, generated allocation rules stored in Rule Data 150 and associated with Leaf Nodes 
720A-720H are accessed using Query Engine 170. Leaf Nodes 720A-720H are 
associated with business objects configured to receive transaction allocations. In some 

15 embodiments, Access Leaf Rules Step 810 is analogous to Access Rules Step 530 (FIG. 
5) except that only generated allocation rules associated witii business objects configured 
to receive transaction allocations are accessed. 

[0079] In an Execute Leaf Queries Step 820, the generated allocation rules accessed 
in Access Leaf Rules Step 810 are used to execute queries on Transaction Data 155. In 
20 some embodiments. Execute Leaf Queries Step 820 is analogous to Execute Queries Step 
540. As in Execute Queries Step 540, the executed queries are typically generated using 
the accessed allocation rules. 
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[0080] In an Identify Unallocated Transactions Step 830, those transactions not 
selected in any of the queries executed in Execute Leaf Queries Step 820 are identified. 
These transactions are considered unallocated. In some embodiments, the unallocated 
transactions are identified by setting an attribute associated with each of the transactions 
5 that are allocated. For example, in one embodiment, each of a set of data records 

includes a "selected" flag and a pointer to an associated transaction. When a tiransaction 
is selected by a query this flag is set. In Identify Unallocated Transactions Step 830 tiiese 
records are searched and unallocated transactions are identified. 
[0081] In an optional Identify Under-allocated Transactions Step 840, ti^sactions 
10 diat are not completely allocated are identified. For example, if a tiransaction includes a 
10% commission on a sale and Execute Leaf Queries Step 820 results in identification of 
business objects configured to receive 8% of die sale, 2% of the sale amount is 
unallocated. Identify Under-allocated Transactions Step 840 typically includes 
comparing a value of a ti-ansaction available to be allocated with a sum of values that 
15 could be allocated to business objects identified in Execute Leaf Queries Step 820. In 
various embodiments, tiie "value" of a transaction is measured in dollars, percentage of 
another transaction, amount of a commodity, amount of time, amount of another 
resource, or the like. 

[0082] In an optional Identify Over-allocated Transactions Step 850, ti^sactions that 
20 are over-allocated are identified. For example, if a tiransaction includes a 10% 

commission on a sale and Execute Leaf Queries Step 820 identifies six business objects, 
each configured to receive 2% of the sale, then 2% of the sale amount is over-allocated. 
As in Identify Under-allocated Transaction Step 840, Identify Over-allocated 
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Transactions Step 850 typically includes comparing a value of a transaction available to 
be allocated with a sum of values that could be allocated to business objects identified in 
Execute Leaf Queries Step 820. 

[0083] In an Allocation Plan Complete Step 860, Allocation Manager 190 is used to 
examine the results of Identify Unallocated Transactions Step 830, Identify Under- 
allocated Transactions Step 840 and/or Identify Over-allocated Transactions Step 850. If 
no transactions have been identified as being unallocated, under-allocated or over- 
allocated in the allocation plan then the allocation plan is complete and the process can 
continue to an optional Allocate Step 865 wherein actual allocation occurs, as discussed 
further herein. If there are unallocated, under-allocated or over-allocated transactions 
then the method continues to an Access Non-Leaf Rules Step 870. 
[0084] In Access Non-Leaf Rules Step 870, Allocation Manager 190 is used to access 
generated allocation rules associated with Root Node 710 and Inteimediate nodes 720A - 
720H. In some embodiments, this step is analogous to Access Leaf Rules Step 810 
except that the accessed generated allocation rules are not necessarily associated with 
business objects configure to receive transaction allocations. 
[0085] In an Execute Non-Leaf Queries Step 880, the generated allocation rules 
accessed in Access Non-Leaf Rules Step 870 and Query Engine 170 are used to execute 
queries on the transactions identified as being unallocated, under-allocated and/or over- 
allocated in Steps 830, 840, and 850, respectively. In some embodiments, one of the 
generated allocation rules used in Execute Non-Leaf Queries Step 880 is configured to 
select all possible transactions, thus ensuring that all transactions will be selected by at 
least one query in Execute Non-Leaf Queries Step 880. 
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[0086] In an Identify Managing Business Objects Step 890, Allocation Manager 190 
is used to identify a person or persons having a role of manually determining the 
allocation of the transactions selected using each query in Execute Non-Leaf Queries 
Step 880. The identification of this person is dependent on the generated allocation rule 

5 on which the query was based and the business object associated witii that generated 
allocation rule. For example, in some embodiments, several unallocated ti-ansactions are 
selected using the generated allocation rule associated with Intermediate Node 720D. 
Intermediate Node 720 is associated with a person (business object) having a "manager" 
role and authorized to manually determine the allocation of tiiese ti-ansactions. The 

10 person having a manager role is optionally also associated with a member of Leaf Nodes 
730A-730N, such as Leaf Node 730G. In some cases, more than one person having a 
manager role will be identified for a particular transaction. Identify Managing Business 
Objects Step 890 is performed for each query executed in Execute non-Leaf Queries Step 
880. 

15 [0087] In a Manual Selection Step 895, ttie allocation of ti-ansactions queried in 
Execute Non-Leaf Queries Step 880 are manually determined by the business objects 
(e.g. person or persons) identified in Identify Managing Business Objects Step 890. For 
example, in some embodiments, a person associated with Intermediate Node 720H 
receives a request to manually determine an allocation plan for unallocated ti-ansactions. 

20 She receives this request because tiie transactions were selected using the generated 

allocation rule associated with Intermediate Node 720H. In some of these embodiments, 
the person associated with Intermediate Node 720H is not configured to receive an 
allocation herself, in otiier embodiments she is also associated with a member of Leaf 
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Nodes 730A-730N, such as Leaf Nodes 730L or 730M, and thus is configured to receive 
allocations. In one embodiment, this person receives a task assigning her responsibility 
to manually plan the allocation of the transactions. The allocation task is optionally 
facilitated by a graphical user interface showing: a partial allocation, why the person was 

5 chosen, business objects associated with daughter nodes of Intermediate Node 720H, 
options (such as an HTML based form) configured for manually completing the 
allocations, allocations to business object associated with Leaf Nodes 730A-730N that 
have already been planned for a particular transaction, and/or the like. In Manual 
Selection Step 895, the determinations made by the business objects identified in Identify 

10 Managing Business Objects Step 890 are typically configured to complete the allocation 
plans of the transactions queried in Execute Non-Leaf Queries Step 880. 
[0088] Following Manual Selection Step 895, the method proceeds to Allocate Step 
865 wherein the transactions are allocated to the business objects specified in steps 820 
and 895. 

15 [0089] Several embodiments are specifically illustrated and/or described herein. 
However, it will be appreciated that modifications and variations are covered by the 
above teachings and within the scope of the appended claims without departing from the 
spirit and intended scope thereof. For example, the various computer systems described 
herein are optionally implemented as distributed systems; likewise the location of 

20 specific data records is optionally varied among a variety of alternative locations. 

Communication between various elements of the invention may occur over the World 
Wide Web or other computer network. The invention is optionally implemented as an 
internet application. 
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[0090] The invention is optionally adapted to alternative types of ordered data 
stinctures that allow inheritance between nodes. In addition, in some embodiments, 
business objects configured to receive an allocation and business objects having 
management roles need not be classified by the type of node with which they are 
associated. In alternative embodiments, altemative methods of identification are used. 
For example, in one embodiment, a role attribute may be used to distinguish business 
objects configured to receive allocations and/or to have a manager role. In this 
embodiment, the role attiibute is used to determine which rules are accessed in steps 810 
and 870. In some embodiments, a generated allocation rule can be empty (e.g., no 
allocation rule is inherited or predefined) and, in some embodiments, the systems and 
methods of tiie invention are used to update existing allocation rules. In some 
embodiments, a generated allocation rule is determined by traversing hierarchical Data 
Stiiicture 200 from a leaf node, to an intermediate node, and then to the root node. In 
these embodiments, the generated allocation rule is generated by collecting predefined 
rules associated with traversed nodes. Embodiments of the invention include computer 
code stored on a computer readable medium and configured to execute methods of the 
invention. 

[0091] In this application "allocation rules" are meant to include both rules used to 
select a business object to receive an allocation resulting from a ti-ansaction and rules 
used to calculate the amount of the allocation. In some embodiments, an allocation of all 
or part of a transaction to a business object is tireated as a new transaction. For example, 
the payment of a conraiission, once determined, is optionally managed as a new 
transaction. 



Solberg et al. 



35 



PA2552US 



